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The NASA Goddard Space Flight Center’s Flight Dynamics Facility (FDF) is a multi- 
mission support facility that performs ground navigation and spacecraft trajectory design 
services for a wide range of scientific satellites. The FDF also supports the NASA Space 
Network by providing orbit determination and tracking data evaluation services for the 
Tracking Data Relay Satellite System (TDRSS). The FDF traces its history to early NASA 
missions in the 1960’s, including navigation support to the Apollo lunar missions. Over its 40 
year history, the FDF has undergone many changes in its architecture, services offered, 
missions supported, management approach, and business operation. As a fully reimbursable 
facility (users now pay 100% of all costs for FDF operations and sustaining engineering 
activities), the FDF has faced significant challenges in recent years in providing mission 
critical products and services at minimal cost while defining and implementing upgrades 
necessary to meet future mission demands. This paper traces the history of the FDF and 
discusses significant events in the past that impacted the FDF infrastructure and/or business 
model, and the events today that are shaping the plans for the FDF in the next decade. 
Today’s drivers for change include new mission requirements, the availability of new 
technology for spacecraft navigation, and continued pressures for cost reduction from FDF 
users. Recently, the FDF completed an architecture study based on these drivers that defines 
significant changes planned for the facility. This paper discusses the results of this study and 
a proposed implementation plan. As a case study in how flight dynamics operations have 
evolved and will continue to evolve, this paper focuses on two periods of time (1992 and the 
present) in order to contrast the dramatic changes that have taken place in the FDF. This 
paper offers observations and plans for the evolution of the FDF over the next ten years. 
Finally, this paper defines the mission model of the future for the FDF based on NASA’s 
current mission list and planning for the Constellation Program. As part of this discussion 
the following are addressed: the relevance and benefits of a multi-mission facility for 
NASA’s navigation operations in the future; anticipated technologies affecting ground orbit 
determination; continued incorporation of Commercial Off-the-Shelf (COTS) software into 
the FDF; challenges of a business model that relies entirely on user fees to fund facility 
upgrades; anticipated changes in flight dynamics services required; and considerations for 
defining architecture upgrades given a set of cost drivers. 


I. Introduction 

The Flight Dynamics Facility (FDF) located at the Goddard Space Flight Center (GSFC) in Greenbelt, Maryland 
is an essential NASA institutional resource that provides multi-mission navigation services for a wide range of 
robotic and human space flight missions. Navigation services include orbit determination, maneuver planning and 
orbit product generation, including the computation and delivery of acquisition data (station pointing data). The FDF 
has a long history of flight project support and has long term commitments to future NASA projects and programs. 

Today, the FDF provides routine ground based orbit determination for eighteen satellites. Included in this 
mission set are science spacecraft such as the Hubble Space Telescope (HST) and the Solar TErrestrial RElations 
Observatory (STEREO). Orbit determination is also provided for the NASA Tracking and Data Relay Satellite 
System (TDRSS). The FDF routinely supports missions in flight regimes that include Low Earth, Geosynchronous, 
Lunar, Libration Point and Heliocentric orbits. The FDF will add mission support for the Solar Dynamics 
Observatory (SDO), Lunar Reconnaissance Orbiter (LRO) and Gamma-ray Large Area Space Telescope (GLAST) 
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missions that are scheduled for launch in 2008. 

In addition to science mission support, the FDF 
is an important component of the ground 
support infrastructure for NASA’s human space 
flight program. The FDF provides routine orbit 
determination for the International Space 
Station (ISS), serves as the backup facility for 
Space Shuttle (STS) orbit determination, and 
generates acquisition data for these two 
programs. The FDF also provides navigation 
products and services to other government 
agencies such as the National Oceanic and 
Atmospheric Administration (NOAA), and 
supports NASA missions operated at 
universities and other non-NASA sites such as 
the University of California at Berkeley and the 
Applied Physics Laboratory. 

Future NASA science missions will 
continue to use the FDF for navigation products 
and services. This includes missions such as the 
Magnetospheric Multiscale Mission (MMS) 
and the James Webb Space Telescope (JWST). In order to be responsive to future navigation requirements, the FDF 
must continue to evolve in order to leverage new technology and present FDF users with cost effective solutions for 
ground-based navigation support. 

The FDF is a fully self-sustaining operation in which users pay for all services and fund all sustaining 
engineering and facility operations activities. In addition to the future technical challenges that face the operation of 
the FDF, the present business operation of the FDF presents management challenges as well, including the planning 
of major upgrades to the facility. Today, all incremental or major upgrades to the facility must be funded by existing 
and/or future FDF users. 

The purpose of this paper is to examine the past evolution of the FDF for lessons learned and to present current 
plans for the “fourth generation” FDF in response to recent and anticipated changes in the future. Fundamental to 
this discussion is whether a multi-mission facility for ground-based navigation computations still serves a purpose 
that can justify the significant changes that are planned to reengineer the current FDF architecture. 

II. The FDF: Current Products and Services 

The FDF provides orbit determination; acquisition data generation and transmission; planning product 
generation; tracking data evaluation and certification; and maneuver planning and calibration services on a regular 
basis. “Full-service” orbit determination is provided for 18 missions. These are typically missions that operate and 
require FDF products and services for many years over the lifetime of the spacecraft. Station pointing data 
(acquisition data) is provided on a regular basis for about 25 missions. This acquisition data is sent to the Space 
Network (SN), Ground Network (GN), Deep Space Network (DSN) and the Universal Space Network (USN). 
Planning products such as station view periods and spacecraft eclipse predictions are provided to various Mission 
Operations Centers (MOCs) to be used for station scheduling and operations planning. Tracking data evaluation is 
performed on a regular basis for the SN and the GN and as part of the launch and early orbit support provided by the 
FDF. Tracking data validation support is also provided for new tracking sites or those that have upgraded their 
equipment. Most recently this service was provided for the LRO and SDO projects. Maneuver planning and 
calibration support are provided for several legacy missions, however for most new missions this function is 
performed in the MOC. 

In addition to full-service missions, the FDF provides support to missions on a short-term or special support 
basis. This support usually covers the launch and early orbit period or times when a spacecraft experiences an 
anomaly. An example of this type of support is a near-Earth spacecraft that uses the Global Positioning System 
(GPS) for navigation. The FDF can provide navigation and acquisition data services to missions for the first 3-5 
days after launch until the onboard GPS solutions are verified. The FDF provides support for approximately 12 
expendable launch vehicles (ELVs) in a calendar year. Support provided includes pre-launch generation of 
acquisition data; near-real-time powered flight data monitoring; updated acquisition data generation and 



Figure 1. FDF Operations Room 
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transmission; and separation vector generation and transmission. The FDF regularly supports Sealaunch, Atlas V, 
and Delta IV launch vehicles carrying both NASA and commercial payloads. 

The FDF has a support role for STS and ISS. The STS support consists of providing acquisition data to SN and 
GN and other sites that support STS. This data includes both nominal acquisition data and contingency acquisition 
data. ISS support consists of processing tracking data and providing orbit vectors to NASA’s Johnson Space Center 
(JSC) for the ISS and acquisition data to the networks. The FDF also provides tracking data evaluation to ISS and 
STS. In addition, the FDF is back-up to JSC for STS navigation for emergency situations. 
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Figure 2. Present FDF Operations Load 


The mission support products generated by the FDF are delivered to users via the FDF product server. Orbit 
planning information is placed on the server so that missions may pull their products when needed. Products 
delivered through the product server include mission planning products, station view periods, state vectors and 
ephemerides. Some acquisition data is delivered through the product server, however, most acquisition data is sent 
directly to the required network. 

The FDF has moved toward generation of a standard set of products over the last several years and away from 
supplying project-unique products. With the availability of commercial software that produces many of the products 
that the FDF traditionally provided using in-house software, it is easier and more cost-effective for the missions to 
receive a standard set of products or ephemeris from the FDF and then generate their own unique set of products. 
This allows the user to customize the product set to their needs and to generate products when needed. It also 
minimizes the number of special requests that the FDF needs to provide. 

The support outlined above is provided using various computing platforms within the FDF. The FDF has 
approximately 70 machines that are a mixture of UNIX and Windows-based servers and workstations. These 
computers provide the application computing, communications, and data processing support for the facility. The 
FDF has a distributed computing architecture with about one third of the machines supporting infrastructure services 
such as communications, data processing and storage and system monitoring. The remaining machines are used for 
operations. When critical operations are performed, processing is restricted to certain machines in order to maintain 
strict configuration control. 

The FDF interfaces with the GSFC Internet Protocol Operational Network (IONet) for its operations. The IONet 
is divided into three subnets. The most secure is the Closed IONet where the FDF performs analysis and operations. 
The Restricted IONet and the less-restricted Open IONet make up the other two segments of the IONet. These 
network connections allow the FDF to reach its customers and provide for data exchange, delivery of products or the 
receipt of data. The FDF interfaces with a wide range of external entities through these networks, including White 
Sands Complex (WSC) for SN support; NASA, U.S. Department of Defense and commercial ground networks; 
launch support facilities; and Mission Control Centers. Data formats and delivery methods vary depending on the 
external interface and entity. 
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III. Evolution of the Current FDF 

The FDF has undergone tremendous change over its long history. In the last 15 years alone, the facility has 
evolved from a mainframe computer facility with institutional funding to a distributed computing environment 
facility that is completely user funded. This change has occurred gradually, and for the most part unintentionally and 
without a systematic process or plan. As a result, the change has left the facility with a system that is often difficult 
to change quickly to meet future mission needs. 

A. The Early Years of the FDF 

The origins of the FDF trace back to the earliest days of the United States space program. In the 1960’s, ground- 
based orbit determination at GSFC was performed by two separate organizations in order to satisfy two distinctly 
different requirements. The first group provided orbit determination for GSFC’s early science missions to enable 
science data processing, spacecraft maneuver planning and scheduling of network resources. The second group was 
part of the original manned space flight ground network. In support of the Apollo program, this group’s role was to 
process tracking data for purposes of validating the data quality of the Apollo Manned Space Flight Network 
(MSFN), providing acquisition data for that network and evaluating the quality of this data for navigation 
computations at JSC. A byproduct of this process was an orbit determination product that could be used as a backup 
to the product generated by the JSC navigation team. This dual role of providing navigation services to science 
missions as well as supporting the NASA Ground and Space Networks with tracking data evaluation services 
continues today. 

By the mid- 1 970’ s the two navigation groups at Goddard coalesced into a single group and through various 
organization changes and consolidation of operations facilities, the entity that we now identify as the FDF came into 
existence in 1985. The facility that existed in the 1980’s consisted of IBM compatible mainframe computers and 
applications software developed at Goddard. Most of this software was FORTRAN based. 

B. FDF Upgrade Planning in the Early 1990’s 

In 1992 the FDF was a modem operations facility that supported a large number of flight projects and the 
tracking networks. Critical operations, routine operations, and contingency operations were supported out of two 
large operations rooms. The architecture was mature and featured three mainframe computers used for all 
operational support as well as analysis and development activities. Each mainframe was rated at 8.4 million 
instructions per second (MIPS) and had 32 megabytes of memory. By today’s standards, this compute power seems 
underwhelming, but it was enough to support a broader range of service requirements than those that exist today. 

A “long range” plan 1 was completed in 1991 to provide a guide “to evolve from current support capabilities to 
those required to meet identified and projected services for flight projects and the networks.” Four goals were 
identified in the document: 

1 . Reduce costs 

2. Provide FDF users with high accuracy navigation products 

3. Maintain a state-of-the-art FDF based on a systematic phased replacement philosophy 

4. Develop staff skills 

Various near-term (5 year) activities were identified to meet these goals. First and foremost was emphasis on 
reducing overall project support costs by reducing FDF software development and maintenance costs. Software 
development and maintenance were seen as the major contributor to the overall support costs and an area where 
savings could be made. This was to be accomplished through an expanded software library, but the primary focus 
was to be the development of the Combined Operational Mission Planning and Attitude Support System 
(COMPASS). . While the Goddard Trajectory Determination System (GTDS) used for orbit determination 
computations was truly generic and supported most new missions with no modification, systems that were required 
for mission trajectory design and attitude determination often required new development or significant modifications 
to existing systems. COMPASS was an effort to develop a generalized flight dynamics system for attitude and 
trajectory design computations that could increase mission-to-mission software reuse to the 80 percent level from 
the traditional 20 percent level. This generalized software system would result (it was believed) in a 50 percent 
reduction in the development costs for new and unique navigation, mission design and attitude software systems 
required for future missions. While this system would effectively replace all of the applications software in the FDF, 
the projected development cost was enormous (greater than 200 staff-years). This effort was eventually discontinued 
for this reason as well as the availability of COTS, new software development approaches and changes in spacecraft 
support requirements that eliminated the need for extensive ground attitude determination computations. Hindsight 
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now tells us that there never would have been an appropriate return on investment to justify the enormous cost of 
this development. 

As part of implementing the 1991 long-range plan, a formal FDF architecture study 2 was completed in 1992 to 
determine the optimum FDF computing environment based on a projected workload over the next 5 years. A look 
back at the conclusions of this study is interesting. At the time, the projected workload was expected to increase in 
complexity and frequency. This 1992 study was grounded in a mainframe perspective and identified an “ideal” 
architecture that had the following characteristics: 

• Portable applications 

• Heterogeneous networks of computing platforms (multiple hardware platforms including mainframes) 
connected together by a Fiber Distributed Data Interface (FDDI) backbone 

• Computing platforms that communicate via protocols that comply with Government Open Systems 
Interconnection Profile (GOSIP) standards. 

• Open systems architecture that would be compliant with Portable Operating System Interface for Computer 
Environments (POSIX) 

With respect to the flight dynamics applications that would be executed in the FDF, the 1992 architecture study 
did not address this in depth but acknowledged the need to continue the COMPASS development effort that was 
underway. In addition to supporting the COMPASS development, the 1992 architecture study supported continued 
automation of FDF products, services and operations to the maximum degree practical. 

Despite the strong desire by the 1992 architecture study team to move the FDF to the “ideal” architecture, it was 
felt that this was not a feasible goal to achieve within a 5 year period due to funding constraints and the risk to 
missions being supported at that time. Another major obstacle noted was the approximately 4 million lines of FDF 
applications software code that was mainframe and FORTRAN based. This software was designed to execute on an 
IBM mainframe compatible architecture under the MVSA/XA operating system and would need to be ported to 
other computing platforms and/or re-architected to take advantage of newer machine architecture and capabilities. 

Therefore, the team’s final recommendation was to develop a “heterogeneous platform” based architecture that 
consisted of replacing current mainframes with more powerful mainframes and gradually moving applications 
software to other platforms in an open systems environment. This was an intermediate step to the “ideal” 
architecture that might be achieved eventually over a 10 year period. In retrospect, the 1992 architecture study 
defined an evolutionary path that was reasonable and in line with the direction of computing technology. The study 
did not, however, address in specific terms the cost of the architecture changes required or present a business case 
for this change with quantifiable benefits in return for a substantial funding investment. Nor did it develop a realistic 
mission model for known and potential mission support. 

The 1992 architecture study focused on defining an FDF architecture while making a general assumption that the 
support requirements for missions would remain generally the same. In 1995, an in-house team examined flight 
dynamics operations concepts of the future and focused on the nature of flight dynamics support in the year 2000. In 
its final report 4 and a subsequent update to the report 5 in 2003, key “operations concept elements” were defined that 
provided guidelines for future operation of the FDF. These had significant implications with regard to the facility 
and its architecture needs. Included were the following elements: 

1. The Mission Operations Centers (MOCs) should be the focal point for all ground attitude determination 
(real-time and near-real-time), product generation, mission design and maneuver support activities during 
routine mission operations. 

2. The FDF should evolve into an orbit-only operations facility. The FDF should house the core expertise at 
GSFC in routine ground orbit determination. While orbit determination may be performed in a MOC, this 
is not the preferred approach. Experience and understanding of orbit determination for various types of 
orbits could be lost if all MOCs provided their own orbit determination. 

3. Strong consideration should be given to onboard orbit determination for future missions. This will require 
the FDF to serve in a backup capacity. Either the MOC or FDF should perform the quality assurance of the 
downlinked solution and produce the required mission products as deemed to be most cost-effective. 

4. A base set of orbit products that can be provided by the FDF should be established. As part of this effort the 
number of TDRS products for end users should be standardized. 

5. The generation of orbit/attitude event prediction products (e.g. sensor viewing, contact prediction) should 
be provided by the ultimate user employing COTS (preferred) or in-house supplied and maintained 
software. 
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6. A centralized, multi-mission Flight Dynamics Product Center with automated capability to generate, 
Quality Assure, and file (accessible by remote users) basic orbit products should continue to evolve and 
serve as the primary mechanism to allow transfer of FDF orbit determination products to outside entities. 

C. A Look Back: Changes since 1992 

The changes that were implemented as a result of the 1991 long range plan, the 1992 architecture study and the 
1995 and 2003 operations concepts paper have brought us to the present FDF. In general, these changes to the FDF 
kept pace with project support requirements. An examination of the evolution of the FDF during this period 
presents many lessons for ftiture planning. 

Consistent with the operations concept elements defined in the 1995 report, the FDF became more focused as a 
navigation facility. Attitude determination support within the FDF ended in 2007 due to improvements in onboard 
capability; changes in mission requirements and operations approach; and new ground processing techniques. For 
many years, unique ground attitude determination software systems had to be developed and integrated in the FDF 
for each new mission. This was a significant ground system cost. In the late 1990’s, a multi-mission software system 
was developed in-house using Matlab®. This dramatically decreased the mission unique development costs. Its 
portability and ease of use by MOC Flight Operations Team members resulted in moving the ground attitude 
determination function to the MOCs. More significantly, onboard systems generally provided attitude knowledge to 
an accuracy sufficient to decrease dependency on ground based computations. 

Out of necessity, the FDF evolved to a distributed computing environment with UNIX and Windows 
workstations. Various commercial off-the-shelf (COTS) software tools began to displace some of the in-house 
developed flight dynamics applications software. Between 1995 and 1997, the FDF embarked on an accelerated 
program to move all applications off of mainframe computers. This was viewed as a step that would result in 
immediate cost savings by eliminating a sizable staff dedicated to mainframe computer operations and maintenance. 
While this was consistent with the long term objectives outlined in the 1992 architecture study, this migration did 
not substantially change the mainframe based architecture and its interfaces and data processing flow. The focus of 
this effort was to “port” old software applications to workstations. This architecture continues today and can best be 
described as an aging infrastructure that is a complex mixture of internal and external interfaces that are becoming 
increasingly expensive to maintain. Its advantage is that it does consist of many proven applications software 
systems that have successfully supported a large number of past missions (and can continue to support future 
missions). Its main drawback is its lack of flexibility and cost to maintain and modify. Modifications to data types or 
interfaces may ripple through many components of the architecture and applications systems. 

Another significant change in the 1990’s regarded the automation and delivery of FDF orbit products. Significant 
cost reduction was achieved in the early 1990’s through the development and use of the Orbit Production 
Automation System (OPAS) and Quality Assurance Automation Software (QA Tool). 3 The late 1990’s saw the 
creation of the FDF Product Center where users could retrieve their products via a web-based interface. Along with 
this, the number of products produced by the FDF was reduced. The generation of secondary or “ancillary” orbit 
products that were project unique was generally moved to the MOCs. 

While orbit maneuver planning is still performed in the FDF for science missions, the last ten years have seen 
this function more likely to be hosted in MOCs. This decision is typically based on specific requirements of a flight 
project and skill needs of the MOC flight operations team. Today, if this function is performed in the MOC, the 
FDF generally provides backup technical support. 

Perhaps the most significant event during the recent history of the FDF that continues to have far reaching and 
significant impact on the FDF and its future direction involves its business operation. Prior to 1998, the Goddard 
Flight Dynamics Division (FDD) was responsible for directing all activities associated with the FDF. Although 
NASA contractor staff provided most of the routine operations support within the FDF, there was active 
management and direction of this work by the NASA civil servant work force within the FDD. This same civil 
servant staff provided leadership of FDF modernization efforts as well. During this period, funding for nearly all 
operations, development and analysis support was provided by NASA Headquarters. Beginning in 1998, NASA 
began a consolidation of operations contracts, gave the contractor team a greater responsibility in managing 
operations and removed management of the FDF from the Goddard Flight Dynamics Division. In 2004, the 
management responsibility for the FDF changed once again. As before, the FDF management became the 
responsibility of the NASA engineering organization that was home to NASA civil servant flight dynamics 
engineers (now the Flight Dynamics Analysis Branch). While this presented a number of challenges to the NASA 
staff, probably the most significant was establishing new business processes to recover operations costs from all 
FDF users. Funding is no longer provided by NASA Headquarters; the FDF is now required to be a fully self- 
sustaining operation. 
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In 2006, the Flight Dynamics Users Council was established as a key element of the FDF operation. This Council 
consists of users and sponsors that are beneficiaries of flight dynamics services at GSFC. The primary functions of 
the Council are to review, critique and reach consensus on support strategies, long range plans and resulting core 
capabilities and resource needs for operating the FDF. The objective is to enhance the flight dynamics services 
offered at GSFC and ensure they are responsive to the near term and long term needs of NASA flight projects 
(robotic and manned), space and ground networks, and technology development programs. Specifically, the Council 
performs the following functions: 

• Serves as advocacy group for long range flight dynamics planning 

• Reviews flight dynamics infrastructure requirements and budget requests; 

• Reviews/approves FDF reengineering plans 

• Represents flight dynamics customers and commits to meeting budget requirements 

• Helps assure visibility of FDF costs and budget submittals 

• Reviews and provides feedback on FDF business models 

Table 1 is a summary and comparison of the FDF between 1992 and the present. Through this period of 
enormous change, the FDF provided successful support to dozens of missions. 


Table 1. Comparison of the FDF: 1992 and the Present 



1992 

2008 

FDF Services 

Navigation services : orbit 
determination, acquisition data 
generation, orbit product 
generation, orbit maneuver 
planning, tracking data 
evaluation 

Attitude services: attitude 
determination, control, 
calibration 

Navigation services: similar to 
1992 services with reduced set 
of orbit planning products; 
routine orbit maneuver planning 
may be performed in MOCs 

Attitude services: none 
performed within the FDF 

Missions supported 

Full Service: 12 
Shortterm: 1 

ELVs: records not available 
STS: 8 

Full Service: 18 
Shortterm: 1 
ELVs: 12 planned 
STS: 5 planned 

Future Mission Model 
(new missions projected over 
next 5 years) 

10 new full service missions 
added between 1992-1997; STS 
launches projected for many 
years 

2 new full service missions 
planned between 2007 -2012; 

12 short term missions; STS 
support ending with uncertainty 
in Constellation Program support 

Approximate Facility Staffing 

175 

(50% for facility operations, 
sustaining engineering , software 
& system maintenance) 

55 

(50% for facility operations, 
sustaining engineering , software 
& system maintenance) 

Computer Platforms 

Mainframes 

Workstations 

Applications 

All In-house 

In-house + commercial software 

Product Delivery 

FDF originated transfer 

Product Center 


Primarily in the FDF 

Mostly MOC based 

Funding Source 

Primarily NASA Headquarters 
funding 

100% user fees 

FDF Management 

NASA division level 
organization; headquarters 
sponsorship 

NASA branch level 
organization; Flight Dynamics 
Users Council for user input 
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D. Anticipating and Responding to Past Change: Lesson’s Learned 

In retrospect, the events of the past fifteen years have given us many “lessons learned” that can be applied today 
as we look to the future of the FDF. Among these are the following: 

• “Flight dynamics operations ” is an engineering sub-discipline and expertise that must be cultivated and 
can be easily lost. In-house knowledge of operations interfaces, ground system design and facility 
architecture is essential for providing effective flight dynamics support to flight projects and leading 
changes necessary for future mission support. 

• A single organization should have end-to-end ownership of all flight dynamics services and operations. 
This assures the FDF evolves based on a clear understanding of future mission needs, and provides the 
flight projects with a single point of contact for flight dynamics mission services. 

• Realistic analysis of future mission models and operations concepts must drive change for the FDF. The 
1992 architecture study had a reasonable view of the direction of facility computer hardware and networks 
but it failed to take a critical look at both the need and delivery of services in the future. Assessing a 
realistic mission model for future architecture and support planning presents a challenge and within the 
FDF there are numerous examples of how we have focused too much or too little on perceived trends in 
new mission support. As important as it is to predict the types of missions to be supported in the future, it is 
just as important to not base a major change in direction on a single view of the mission model. An overly 
optimistic view of the mission set, including increases in numbers of full service missions to support (many 
formation flying or constellation missions) characterized FDF planning in the late 1990’s. 

• Facility architecture issues can not be deferred indefinitely. While the accelerated approach to moving off 
of the mainframe computers achieved a significant level of success with respect to reducing costs of system 
hardware and maintenance, the “quick and dirty” approach did not address architecture improvements that 
are now becoming critical for efficient operations in the future. 

• COTS software has become an important part of the suite of applications software in the FDF. Much of the 
focus on cost reduction in the early 1990’s was to reduce the cost of in-house software development and 
maintenance. COTS software, especially for database management, orbit product generation and maneuver 
planning, has helped accomplish this goal. However, COTS software will not eliminate the need for some 
in-house developed software. 

• Simple and clear strategic plans can provide valuable guidance and direction to an organization. While we 
often focus on how we fail to anticipate future events, we can point to some correct predictions made (e.g. 
COTS, changing operations concepts in support of autonomous navigation) that influenced the FDF 
planning in a positive way. 

• A multi-mission operations facility such as the FDF can operate as a fully self-sustaining operation. We 
believe the services offered are cost-competitive given new customers that have made commitments for 
future support. While some services provided by the FDF are not critical for the maintenance of core 
expertise or the development of new and interesting capabilities, they are, nevertheless, important to offer 
to customers in order to help maintain the FDF infrastructure. Routine activities such as ELV support are 
important to help maintain a base of funding for the FDF infrastructure. Key to the success of this business 
approach is active communication with FDF users. The establishment of the Flight Dynamics Users 
Council was essential for discussing requirements for FDF support and negotiating funding commitments. 

• System architectures must be flexible in order to respond rapidly to change. The FDF system architecture 
envisioned in the early nineties was one that did not change both from a hardware or software perspective. 
Today, a long hardware lifetime is 10 years, and software needs to be flexible to accommodate multiple 
operating system changes. Add to that the ever changing IT security needs and any system needs to accept 
changes without major modifications. 

• Spacecraft autonomous navigation systems (e.g. GPS) have begun to change and will continue to change 
the support requirements for the FDF. This is clearly a positive development for spacecraft navigation and 
the FDF must continue to adapt to focus on short term (early mission) or anomaly support to Earth orbiting 
missions with navigation autonomy. 

E. The Case For Continuing A Multi-Mission Navigation Facility at Goddard 

Over the last ten years there has been occasional debate regarding the use and merits of a multi-mission facility 
such as the FDF for ground navigation services versus the integration of all ground navigation functions in MOCs. 
We already have a history of moving the ground attitude determination functions from the FDF to MOCs. When 
computing systems were mainframes and funding was provided by a central organization, the use of multi-mission 
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support facilities made sense from both a business perspective and technical perspective. With the introduction of 
distributed computing capability, the availability of COTS for flight dynamics functions and the increasing 
sustaining costs of a multi-mission facility, the use of a multi-mission support facility may not be the most cost 
effective. However, if the sustaining costs can be scaled to the needs of the users, there are advantages to having a 
facility that supports multiple users. For missions that use GPS for navigation but need ground based navigation 
services for the first few days of the mission, it is not cost effective to set up a system in the MOC to perform that 
short term support. The FDF can provide these services in a cost effective manner. Another advantage to a multi- 
mission support facility is that it helps maintain important navigation skills; support personnel gain experience in 
different types and conditions of missions. Knowledge of what to do in a contingency and having support personnel 
readily available and experienced in navigation can be an asset in case a mission has a contingency. 

There is no single solution that fits all mission types and mission requirements. FDF personnel have often 
assisted in development and/or testing of navigation systems located in MOCs and the FDF has served as a backup 
during early mission operations for this type of approach. For the foreseeable future, operation of a multi-mission 
navigation facility (the FDF) continues to serve a major purpose. To summarize, we see the following advantages to 
using a multi-mission facility for meeting many (but not necessarily all) of GSFC’s future navigation needs: 

• The FDF provides a focus and a home for institutional expertise in operational orbit determination and 
tracking systems that can be made readily available for resolving spacecraft anomalies, providing 
consultation on all navigation issues and mission concept development. 

• The cost of maintenance of navigation systems (including license fees for COTS software) can be shared 
by many customers. 

• Certain FDF functions are clearly not easily located in MOCs and are multi-mission in nature. This 
includes tracking data evaluation. 

• A larger and greater suite of navigation tools and supporting software systems are generally available for 
on-orbit analysis and troubleshooting in a multi-mission facility. 

• All necessary interfaces with the many tracking networks are already available and tested with the FDF and 
do not have to be replicated for each new mission. 

• FDF products and services remain cost competitive with other approaches for ground navigation support 

Intuitively, these advantages go away as the mission set supported by the FDF becomes very small. The size of 
the FDF has been reduced and it is acknowledged that it must be scalable in the future to the mission set. This is one 
motivation for the reengineering effort discussed later in this paper. However, at some point the cost of services 
from a multi-mission facility will not be competitive due to certain fixed costs inherent with operating such a 
facility. Through the various FDF planning exercises, this crossover point has not been determined. In a qualitative 
sense, the feeling is that with the additional scalability that will be realized by continued reengineering of the 
facility, the FDF will remain viable as a multi-mission facility to the missions planned through the next decade. 

IV. Current Drivers for Change 

While the present systems and software within the FDF are sufficient to support the current missions and could 
be modified to support new mission requirements, without a fundamental change in the architecture and approach to 
mission support, the FDF would be unable to take advantage of new or recent technology or respond to new mission 
requirements and implement system changes in a timely and cost-effective manner. The costs of maintaining legacy 
software and hardware increase as time goes by, which in turn increases the facility sustaining costs. Additionally, 
the ability of these legacy systems to support future missions decreases over time as missions become more complex 
or requirements change. Having a flexible and adaptable infrastructure assures that the FDF is able to support the 
present missions, and is able to adapt to future mission requirements with minimal impact. 

Some of the drivers for facility modernization are mission requirements, cost reduction, and technology. Details 
of these drivers are given below. While these are not all inclusive, they represent the ones that we consider the major 
drivers for change in the FDF. 

1. Mission Requirements 

One of the biggest challenges for future FDF operations is to ensure the FDF staffing (both direct support 
staff and sustaining engineering support staff) is scaleable to the overall work flow so that the loss of one 
significant customer does not present increases in cost to other customers. An FDF “mission model” is 
maintained to provide insight into user needs and the projected level of activity in the FDF. Looking to the 
future, fewer missions will require services and the level of service will also change. In general, the need for full 
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service flight dynamics support will decrease. However, the missions that do require FDF support throughout 
their lifetime tend to be more demanding and complex. Many near Earth missions are using onboard navigation 
and as a result only need support the first week after launch. Many robotic missions do not have 24/7 support and 
as a result, require some level of automation. Smaller and less-costly missions only require support for short 
periods or as backup/contingency. 

Figure 3 depicts the latest mission model for the FDF. One uncertainty with the mission model is the role of 
the FDF with NASA’s Constellation Program. FDF support to the STS accounts for approximately 20 percent of 
the work in the FDF (as measured by funding). Early discussions with JSC regarding support to the Orion 
manned vehicle have focused on FDF support similar to STS (backup orbit determination and generation of 
acquisition data). Whether or not the FDF ultimately has a role with the Constellation Program, there will be 
some loss of work after the retirement of the STS. 
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Figure 3. FDF Mission Model 


2. Cost 

Limited budgets for existing missions and a no-growth mission base do not allow for the upkeep of a large 
infrastructure. To maintain a viable facility we need to keep a customer base by supplying quality support for a 
reasonable and fair cost. This becomes a challenge without efficient and flexible systems and as more missions 
require only short-term support. FDF users pay for the “direct” cost associated with generating an FDF product. 
In addition, a key component of the cost passed to FDF users is the cost for sustaining engineering support and 
basic facility maintenance. This is the area with the greatest potential for cost reduction and is highly dependent 
on the FDF architecture. 


3. Technology 

There are many technologies that have been developed over the past ten years that are driving the future of 
the FDF. The use of the internet has changed the data communication for mission support. Most missions today 
use Internet Protocol (IP) and communicate over various networks. This has created the need to establish 
communications with multiple networks for operations. Network security is a major consideration. The use of 
databases allows for easier storage and retrieval of data. The computing hardware available today provides for 
more computational capability at a lower cost. The availability of COTS software reduces the need for legacy or 
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in-house developed software; however the system must be more easily integrated into the FDF. Taking 
advantage of all of these requires a system that is easily adjusted and modified. 

The concept of data-driven systems is being used in mission operations. Processes are executed based on the 
availability of data and delivery occurs when products are available. System automation and an architecture that 
supports lights-out operations are essential to providing cost-effective flight dynamics support. 


V. Fourth Generation FDF (2012): GMSEC-Based Architecture 

By 2004, it became obvious that the FDF required substantial upgrades to meet future mission requirements in a 
cost-effective manner. More important, the existing architecture was very inflexible with regard to integrating new 
applications packages, including commercial software systems for spacecraft navigation computations. While the 
facility continued to evolve in what can be characterized as incremental steps driven by near-term needs, the overall 
architecture and infrastructure of the FDF was in need of a substantial technical refresh given that much of the 
computer hardware, software, architecture and configurations were virtually unchanged since migration of the FDF 
off of mainframe computers in the mid-1990s. Unfortunately, establishing new business processes (in which we had 
to transition to a fully reimbursable operations facility) and the need for many short-term security upgrades took 
priority. An internal document 5 produced in May of 2004 identified many of these short-term priorities. In early 
2007, an architecture study team was commissioned to analyze architecture options for the future. This team 
completed their efforts in late 2007 with a set of recommendations for FDF modernization. 

A. Architecture Study Recommendations 

The Architecture Study Team identified two overarching requirements for modernizing the FDF. First, the FDF 
architecture must support the mission model. The effect of this requirement is not only to scale the size of the 
facility and its architecture to the number of missions to be supported, but to also drive the need for greater 
flexibility to support project needs. For example, the JWST mission will have position determination accuracy 
requirements that will drive the need to use an orbit determination system different from the standard Goddard 
Trajectory Determination System (GTDS) used by most missions supported in the FDF. A COTS system is 
currently under evaluation for use by JWST. The architecture must be able to accommodate the rapid and low-cost 
integration of this and other new applications systems into the FDF. 

The second overarching requirement is that the new architecture must reduce sustaining engineering and facility 
operations costs. These “indirect” costs are paid by FDF customers. While sustaining engineering and facility costs 
are now less than 30 percent of the same costs in 1992, they remain a significant cost incurred by FDF customers. 

Consistent with the overarching requirements, the team performed analysis of architecture requirements and 
concluded that the new architecture must provide the following: 

• Rapid and simple application system changes/upgrades 

• Database data synchronization and automated failover 

• Easy deployment of new communication interfaces with required security measures 

• System-wide monitoring - fault detection, prevention, notification, automated recovery 

• Receive / transmit data over multiple networks 

• Publish / subscribe compliant applications that support interactive or automated modes 

• Automatic product generation and delivery for routine operations 

• Automation - routine for lights out; automated load distribution 

• Security - support for NASA security standards 

The architecture team did not perform an in-depth evaluation of all FDF applications software. However, the 
team did recommend that some legacy software systems be replaced or reengineered. In response to the architecture 
requirements, the final recommendation was to re-engineer the FDF with the Goddard Mission Services Evolution 
Center (GMSEC) Architecture. GMSEC is a data/event driven architecture that uses a publish/subscribe message 
bus middleware. Figure 4 depicts the FDF under the proposed GMSEC architecture. In addition to simplifying 
interfaces, the GMSEC architecture provides “situational awareness,” system-wide control, and event driven 
automation. It also enables rapid introduction of new applications software and simplifies the addition of new 
tracking data formats and types. Adding credibility to the recommendation was an analysis of the “business case” 
for using the GMSEC architecture. This included an evaluation of operations savings (presented later in this paper). 
As a self-sustaining operation, reengineering resources must be paid by current FDF users. Thus, a major 
development activity with additional costs levied on FDF users was not a viable option. 
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B. GMSEC Fundamentals 

The GMSEC ground architecture development was begun in 2001. Today, it is a mature architecture that has 
been adopted by many of GSFC’s flight project ground systems. 6,7 It was developed out of the need to reduce 
operations costs, make it easier to incorporate new technology and COTS into ground systems, and reduce 
duplication of efforts between various ground system development efforts. The technical approach for GMSEC is 
based on several important concepts: 

• Standardized interfaces - by standardizing interfaces and not components, the user is able to select the tool 
that best fits mission requirements. 

• Middleware Infrastructure - GMSEC revolves around a message oriented middleware. This middleware can 
be commercial, open source or GSFC-developed. 

• User chooses components - GMSEC allows the users to select the components that best fit their needs. The 
architecture also facilitates the use of legacy components. 

• General purpose approach - GMSEC is designed to be usable for many different missions and domains. 
GMSEC was originally applied to spacecraft ground systems, yet it is well suited for the FDF system. 

The GMSEC architecture uses a message bus for communication between processes or nodes. What used to be 
achieved with socket communications is now accomplished over the message bus. The processes or nodes only 
interface with the bus which simplifies communications for each component. 

The publish/subscribe concept is used for passing information across the bus. An application will publish 
information (data) to the bus via messages. These messages have a subject name and message content. An 
application that needs this data or information will then subscribe to this message. The bus then delivers the message 
to the applications that subscribe to it. 

Many middleware packages use the publisher/subscribe method; however, the message structure for a given 
middleware is proprietary. As a result, different types of middleware are not compatible with each other and an 
application written to interface with one middleware is not compatible with another middleware. GMSEC has 
addressed this issue by having a GMSEC Application Programming Interface (API). The API standardizes the 
capabilities of different middleware so that they appear the same to an application. Having a GMSEC API allows for 
change-out of middleware should a vendor go out of business, to switch to a lower cost middleware product or 
upgrade to a newer product. This GMSEC API supports many operating systems, languages and platforms. This 
makes it an important component in the GMSEC architecture. 

In addition to the GMSEC API, GMSEC has message standards that facilitate the use of various applications 
within the architecture. These message standards make it easy for vendors and developers to make an application 
GMSEC-compatible and simplify the integration of applications. 

A component is considered GMSEC-compliant if it meets certain standards. A component must 1) follow 
GMSEC standard message definitions; 2) publish a heartbeat message on a regular basis; 3) publish status/log 
messages and 4) be able to receive user directives for its control over the bus. 

C. Justification for GMSEC in the FDF 

Due to the extensive work at Goddard in developing the GMSEC architecture including the middleware and 
various support tools, it was not difficult to conclude the GMSEC Architecture will allow the FDF to upgrade and 
modernize with a modest investment. However, the most significant justification for adopting the GMSEC 
architecture is its ability to meet FDF modernization requirements for flexibility. The Architecture Study Team also 
offered the following rationale for moving ahead with a GMSEC based architecture: 

• There is substantial corporate knowledge, compliant components, tools and support available for the 
GMSEC based architecture. 

• GMSEC architecture is mature enough to allow immediate implementation. 

• GMSEC architecture supports phased and gradual introduction. 

• Use of the GMSEC architecture leverages prior (and substantial) investment in both time and money. 
Examples include: 

Evaluating and selecting communication mechanisms 

Developing message standards, interfaces, tools and mechanisms for communication 
Developing and validating tools for autonomy, failover and system monitoring 
Creating an extensive development environment with support tools and message generation and 
monitoring tools 

Successful history of multiple mission verification and validation 
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Supporting multiple platforms, languages and middleware 
Getting buy-in from the missions and establishing the new interfaces 
• New mission data types and applications software can be developed and tested without interference with 
present operations. 

Less time spent testing and integrating into operations systems 
Overall development to operations time reduced 



Evolving to a GMSEC architecture will result in mission cost savings by reducing sustaining engineering staff. It 
will also enable new operations and introduction of new applications and tools. For example, MOCs will be able to 
connect directly to the FDF using secure GMSEC middleware connections and autonomously request and receive 
FDF products. In this model, the MOC would request services and data through GMSEC messaging, and the 
appropriate application would respond. The potential exists and is being explored for this service request model to 
be used between the FDF and other NASA centers. 

D. Return on Investment 

An initial estimate of the cost to implement the GMSEC architecture in the FDF was 40 staff-years, dependent 
on a number of factors including skill level of the development staff (prior experience with GMSEC is highly 
beneficial) and implementation period. A significant effort was expended to show how this level of cost could be 
justified based on cost benefits with the proposed GMSEC architecture. As previously stated, the GMSEC 
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architecture supports phased and gradual introduction into an existing operations environment. This provides great 
flexibility in implementing the new architecture. This is especially important in an operation that is severely cost- 
constrained and must make use largely (if not completely) of existing sustaining engineering staff for implementing 
the new architecture. Intuitively, GMSEC offers the FDF the following cost benefits: 

• Improved efficiencies in operations 

• Lower sustaining engineering costs 

• Savings in implementing new capabilities 

The study team did not quantify the cost benefits due to increased automation of operations processes. There 
have been significant gains in efficiencies in the past with automation 2 and it was believed the GMSEC architecture 
would enable more automation of routine processes for orbit determination and product generation. However, the 
more significant cost benefits were determined to be found in lower sustaining engineering costs for the facility. 
This includes routine software maintenance activities as well as costs for “facility managers” to operate, monitor and 
troubleshoot system-wide operation of the FDF system. The first step in the analysis performed by the architecture 
team was to identify all elements of sustaining engineering costs (staff) and identify those that were fixed (security, 
property management, etc.) versus those that were architecture dependent (such as software maintenance). The 
architecture team worked with current sustaining engineering staff to determine the reduction in the cost of these 
“recurrent” architecture-dependent activities that could be realized with a reengineered FDF. 
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Figure 5. Tracking Data Modifications under Present and GMSEC Architecture 
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More quantifiable savings were identified in the area of implementation of new FDF capabilities. The FDF must 
often add new tracking data types or new applications software to meet project requirements. A recent example is 
the addition of the new Track 2-34 tracking data format to the FDF orbit determination process. The study team 
examined this modification in detail to compare and contrast the process and costs for the modification under the 
current and the GMSEC architectures. These results are summarized in Table 2. Under the current architecture, these 
modifications were performed and required multiple changes to operations software systems. Under the GMSEC 
architecture, this new tracking data type would require modification to a single applications system and table 
updates (see Figure 5). An additional benefit is that development and testing can be performed without impact to any 
operations. 

While GTDS will remain the primary orbit determination system within the FDF for some time to come, the 
FDF uses one COTS package for performing orbit determination for some of the missions it supports and will likely 
add other navigation packages in the future. Newer applications software systems for performing other FDF 
functions are also anticipated. These will be both in-house and commercial products. The study team also examined 
the cost of adding a new orbit determination application under the old and new GMSEC architectures and this is also 
summarized in Table 2. 


Table 2. Estimated Savings with GMSEC Architecture 


Function 

Estimated Savings with 
GMSEC architecture 
(staff years) 

Sustaining Engineering 


• Operations Engineer 

2.0/year 

• Hardware 

0.2/year 

Maintenance 


• System Engineering 

0.2/year 

• Software 

4.0/year 

Maintenance 


• Total 

6.4 / year 

Addition of new tracking 

0.9 

data format ( based on Track 
2-34 modification) 


Addition of new Orbit 

3.0 -5.0 

Determination Application 



E. Implementation Plan 

The recommendations of the Architecture Study Group were accepted by FDF management and endorsed by the 
Flight Dynamics User’s Council earlier this year (2008). A plan to move forward with the implementation of the 
new architecture was also developed. This plan included the implementation phases, the Work Breakdown Structure 
(WBS), schedule and staffing. As a fully self-sustaining operation, the challenge of a major upgrade such as this is 
to find the resources (funding) to implement the new architecture. As stated previously, an effort of approximately 
40 staff years was estimated. A five year implementation plan was initially proposed as a “reasonable” period to 
have most of the GMSEC architecture in place prior to support of the JWST mission and potential support to the 
NASA Constellation Program. This time period also appeared to work well with assumed resource limitations. With 
this schedule, more than 70 percent of the resource requirements can be met by reprioritizing current FDF system 
and software maintenance efforts, suspending any further maintenance on many legacy FDF software systems, and 
redirecting existing sustaining engineering staff. Thus, the challenge remains to find additional funding 
(approximately 12 staff years) for this effort. Various options are currently being explored by GSFC management. 
As Table 2 indicates, this investment would be paid back in FDF sustaining engineering cost savings in 
approximately 2 years. At the direction of GSFC management, the architecture team also developed a plan along 
with funding estimates for a three year implementation. As expected, this faster plan has a significant impact on 
required additional staffing. 
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Implementation of the GMSEC architecture has begun and consists of three phases of development. Phase 1 will 
address the communications and data base processing infrastructure. It was determined that this was the area where 
the most improvement could be made with early benefits available to current missions as well as future missions. 
Phase 2 will focus on process engineering and upgrades of legacy applications. Legacy systems such as GTDS will 
be reengineered to interface with the GMSEC middleware. Recent reengineering of the Acquisition Data Generator 
(ADG) software has given the team confidence in its estimates of effort to do this and ability to meet schedules. 
Several legacy systems that perform front end processing of tracking data will be retired and a new front end 
communications processor will be brought on-line. Finally, phase 3 will address data delivery functions, incorporate 
new end-to-end automation for the generation and delivery of many FDF products, and complete reengineering of 
legacy applications. The reengineering effort is scheduled for completion by the end of 2012. 

VI. Summary and Conclusions 

The FDF is a multi-mission support facility that has been in existence for more than thirty years. It has evolved 
to meet continuously changing needs of NASA flight projects. A major upgrade to the FDF architecture is now 
necessary to both reduce sustaining engineering costs that are currently borne entirely by FDF users and to be able to 
meet requirements for rapid introduction of new flight dynamics applications and operations concepts for future 
missions. Adopting the GMSEC architecture should enable the FDF to continue to provide navigation services to 
missions in the future, and it has been shown to be cost-effective to implement this upgrade under the FDF’s new 
business model. 

This paper included a look back at some past planning efforts for the FDF and presented “lessons learned” for 
similar efforts in the future. With the completion of the recent architecture study and startup of the FDF 
reengineering effort, some additional comments and conclusions can be made: 

1 . The work of the architecture study has reinforced the belief that the FDF, as a multi-mission facility, remains a 
viable and cost effective source of navigation services. This paper was not intended to present a comprehensive 
defense for continued operation of a multi-mission operations facility for future mission navigation services. 
However, a reengineered FDF will continue to provide services that are sufficiently cost-competitive to 
maintain an influx of new business. There are other arguments that can be made for a centralized navigation 
facility (maintenance of core competency, security issues, etc.), but these need not be made if the cost of 
services is attractive to flight project customers. 

2. Our experience seems to indicate that a strategic planning activity for a multi-mission facility such as the FDF 
must be performed at a minimum of every five years. The FDF has never maintained a formal strategic planning 
cycle. Our attempts at long-range planning have been spaced at roughly five-year intervals, usually by accident 
rather than a clear process that requires a periodic planning activity. While we may have benefited from a more 
vigorous process that emphasized more frequent updates to our long-range plans, the 5 year cycle has been 
adequate. 

3. Maintaining a realistic mission model is essential. Many of the flaws in planning activities in the 1990’s can be 
traced to not having a well understood mission model. Because it is mission-funded, the FDF must be more 
responsive and adaptable to changes in mission requirements (for example, short term early mission support to 
missions with autonomous navigation systems), and its size must be scalable such that individual users will not 
face cost increases for services as the FDF customer base changes. 


Appendix: Acronyms 


ADG 

Acquisition Data Generator 

API 

Application Programming Interface 

COMPASS 

Combined Operational Mission Planning and Attitude Support System 

COTS 

Commercial OfF-the-Shelf 

DSN 

Deep Space Network 

ELV 

Expendable Launch Vehicle 

FDD 

Flight Dynamics Division 

FDDI 

Fiber Distribution Data Interface 

FDF 

Flight Dynamics Facility 

GLAST 

Gamma-ray Large Area Space Telescope 

GMSEC 

Goddard Mission Services Evolution Center 
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GN 

Ground Network 

GOSIP 

Government Open Systems Interconnection Profile 

GPS 

Global Positioning System 

GSFC 

Goddard Space Flight Center 

GTDS 

Goddard Trajectory Determination System 

HST 

Hubble Space Telescope 

IONet 

Internet Protocol Operational Network 

IP 

Internet Protocol 

ISS 

International Space Station 

JSC 

Johnson Space Center 

JWST 

James Webb Space Telescope 

LRO 

Lunar Reconnaissance Orbiter 

MIPS 

Million Instructions Per Second 

MMS 

Magnetospheric Multiscale Mission 

MOC 

Mission Operations Center 

MSFN 

Manned Space Flight Network 

NASA 

National Aeronautics and Space Administration 

NOAA 

National Oceanic & Atmospheric Administration 

OPAS 

Orbit Production Automation System 

POSIX 

Portable operating System Interface for Computer 

SDO 

Solar Dynamics Observatory 

SN 

Space Network 

STEREO 

Solar TErrestrial RElations Observatory 

STS 

Space Transportation System 

TDRSS 

Tracking Data Relay Satellite System 

USN 

Universal Space Network 

wsc 

White Sands Complex 
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